Date: Sun, 28 Nov 93 04:30:14 PST
From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu>
Errors-To: Ham-Digital-Errors@UCSD.Edu
Reply-To: Ham-Digital@UCSD.Edu
Precedence: Bulk
Subject: Ham-Digital Digest V93 #126
To: Ham-Digital


Ham-Digital Digest          Sun, 28 Nov 93       Volume 93 : Issue  126

Today's Topics:
                        ATM on Amateur Radio?
                     Ham Radio - Internet gateway
                       wb7tpy gateway (3 msgs)

Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu>
Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu>
Problems you can't solve otherwise to brian@ucsd.edu.

Archives of past issues of the Ham-Digital Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Sat, 27 Nov 1993 21:38:26 GMT
From: swrinde!gatech!udel!darwin.sura.net!ra!atkinson@network.ucsd.edu
Subject: ATM on Amateur Radio?
To: ham-digital@ucsd.edu

In article <CH0n75.CM2@cunews.carleton.ca> im@hydra.CARLETON.CA (Ian McEachern VE3PFH) writes:

>First off there is nothing saying that Amateur Radio ATM will need
>26 Mbps, or anything on that order to do something usefull.

No, but the overhead due to ATM cell size and header structure is
high.  On top of that, one has ATM Adaptation Layer overhead (again
not trivial) and then one has to have some way to format the user
data.  This WILL consume much more bandwidth than is taken up at
present.

>The telco standards people are looking to map ATM cells onto T1
>carriers right now, and when that is done there is talk that
>they'll map ATM cells onto DS0's too!

None of which means that it makes any sense, particularly from a
bandwidth perspective.  IP/T3 has much more useful bandwidth than
IP/ATM/T3.  The same is true whether one has T3 or T1 or DS0 or
some lower bandwidth.

>Secondly there could be some interesting benefits to a Ham implementation
>of ATM.  Can you imagine a data standard that could pass both voice, data
>and video with appropriate handling?  

IP can do this today over low-bandwidth channels.  With the
implementation and deployment of real-time flow support and resource
reservation (e.g. as proposed in the RSVP protocol specification), it
should be even better suited for this.  Of course, ATM is much more
sexy to talk about even if it isn't as good a solution technically...

>Expand your mind abit further and imagine an ATM switch on the Phase 4
>Ham satellite, to switch your packets quickly over to the beam
>on europe, to download the latest version of GRINOS, while simultaneously
>enjoying a ragchew with a group of VK's in the outback, through
>the beam pointed towards Auz. 

ATM switches have real problems with cell loss and congestive
collapse.  The features that you describe all are a function of the
bandwidth available much more than which link protocol (ATM is after
all a kind of link/subnet protocol) is in use.  ATM is a very high
overhead approach to those problems.  Running normal IP would be a
much more appropriate solution.

>I think the big benefit of something like ATM will be integrating
>voice and data in the ham world!

IP can do this now with less bandwidth than ATM would require.  The
machines on my desk move audio, video, and data between three
continents in real-time just fine, sharing bandwidth with ftp and
telnet and smtp sessions.  One can't do it very well at 9600 baud with
ANY technology though.  Compressed voice and full-motion video still
require a whole lot of bandwidth by Ham standards.

ATM is mostly hype at this point, consider what the ATM specifications
really say before claiming that ATM is a likely solution to any problem.
In general, the Ham community garnered its good reputatioin by applying
science to its problems.  Let's keep up that tradition.

------------------------------

Date: 25 Nov 1993 06:45:56 GMT
From: koriel!sh.wide!wnoc-kyo!daemun.rcac!reseau!kenji@ames.arpa
Subject: Ham Radio - Internet gateway
To: ham-digital@ucsd.edu

In article <rcrw90-231193082417@node_13059.aieg.mot.com> rcrw90@email.mot.com (Mike Waters) writes:
 |In the US a packet message is "third party traffic" for the relaying
 |stations no matter *who* originates it.  If a ham originates the message
 |then only the link from the first station to the BBS or relay is non "third
 |party".

You're right. Maybe not only in the USA.

 |On the other hand ham radio can well be used to supplement other services. 
 |Emergency response is one of the most obvious of these.

I also want to emphasize this point - 

 |Personally I think we should be able to carry much of Netnews via ham radio
 |for example (or at least FIDO!).  As far as I know that is not done today.

We're running our own NetNews groups in Japanese called ampr.*. There
are some other local newsgroups here.

 |There are Internet/PBBS gateways for E-mail though, although they tend to
 |be somewhat awkward to use.

Quite a few PBBS operators in Japan do not want to see messages of
non-licensees. I am against this attitude so I don't run nor recommend
people to run PBBS nodes.

 |Another use I have seen is for a yacht in the South Pacific to submit an
 |article via packet to a (nonprofit) club magazine in Ft. Lauderdale. 
 |Appeared to work very well and was much faster than the mail in that part
 |of the world.

A practical use of ham radio - ham radio people must support
non-profit activities, I believe. Otherwise, airwave bandwidth for ham
radio people should be reallocated for other public services.

// Kenji
--
Kenji Rikitake <kenji@k2r.or.jp> <kenji@rcac.astem.or.jp>    (More available!)
Persuade me you may, but I won't be persuaded.                 -- Aristophanes

------------------------------

Date: 25 Nov 1993 06:54:22 GMT
From: koriel!sh.wide!wnoc-kyo!daemun.rcac!reseau!kenji@ames.arpa
Subject: wb7tpy gateway
To: ham-digital@ucsd.edu

In article <2d08eo$mi4@wvhpadm1.mentorg.com> hanko@wv.mentorg.com (Hank Oredson) writes:
 |The real problem here is that the inter-network router somehow "forgot"
 |that BBS network domains have an implied "ampr.org" at the end of them.
 |As in w0rli@w0rli.or.usa.na.ampr.org ...

It's all up to ampr.org domain administrator (namely Brian Kantor) to
accept this or not.

// Kenji

--
Kenji Rikitake <kenji@k2r.or.jp> <kenji@rcac.astem.or.jp>    (More available!)
Persuade me you may, but I won't be persuaded.                 -- Aristophanes

------------------------------

Date: 25 Nov 1993 06:51:58 GMT
From: koriel!sh.wide!wnoc-kyo!daemun.rcac!reseau!kenji@ames.arpa
Subject: wb7tpy gateway
To: ham-digital@ucsd.edu

In article <2ctoto$h25@wvhpadm1.mentorg.com> hanko@wv.mentorg.com (Hank Oredson) writes:
 |What routing information?

The requirement of including regional/geographic information into the
mailing address. This will not work.

 |These are NOT routes we are talking about ...
 |they are locations ...

Locations are geographic information :)

 |I think all the bbs authors understand that a location is
 |not a route, and address is not a route nor a location,
 |etc. etc.

People tend to interpret location info can be used for routing. This
doesn't work. See "The Internet Message - Closing The Book with
Electronic Mail", by Marshall T. Rose for how OSI X.400 failed by not
specifying resolution mechanism between addresses and routes.

// Kenji
--
Kenji Rikitake <kenji@k2r.or.jp> <kenji@rcac.astem.or.jp>    (More available!)
Persuade me you may, but I won't be persuaded.                 -- Aristophanes

------------------------------

Date: 25 Nov 1993 06:59:56 GMT
From: koriel!sh.wide!wnoc-kyo!daemun.rcac!reseau!kenji@ames.arpa
Subject: wb7tpy gateway
To: ham-digital@ucsd.edu

In article <2ctpip$h25@wvhpadm1.mentorg.com> hanko@wv.mentorg.com (Hank Oredson) writes:
 |If people would simply STOP trying to connect the two networks,
 |the problem would just go away.

I disagree. At least some part of ham radio community want to
communicate with Internet. And I see no ethical issues on connecting
these networks, although laws must be changed.

 |Now folks want to connect them.

yes.

 |There is certainly no problem creating some new top level domain
 |for the bbs network - but why bother?  We have one already: it
 |is ampr.org ... so what is the problem with using that at the gates?
 |Anything that came from the bbs net gets appended .ampr.org when it
 |moves to the internet.  Same thing the other way: the .ampr.org gets
 |dropped once the traffic is inside that net.

In near future PBBS systems should be re-written to keep ampr.org
INSIDE the network. Mail addresses should be treated as is.

 |Is there some problem with this concept?

I think it's ok as long as ampr.org domain administrator agrees.

 |w0rli@w0rli.or.usa.noam.ampr.org - no big deal for any router to handle.

No. :)

 |Oh yes, I know about the issues with tcp/ip - but tcp/ip within the bbs net
 |is yet a different issue.  One still needs the hierarchical location
 |information, since many services do indeed use those identifiers as routing
 |hints (ROUTING HINTS, not ROUTES ...) and we would like to continue to do
 |so.

Well, in fact. parsing identifiers to obtain routing information is
acceptable.

// Kenji
--
Kenji Rikitake <kenji@k2r.or.jp> <kenji@rcac.astem.or.jp>    (More available!)
Persuade me you may, but I won't be persuaded.                 -- Aristophanes

------------------------------

Date: 23 Nov 93 16:35:18 CST
From: timbuk.cray.com!hemlock.cray.com!andyw@uunet.uu.net
To: ham-digital@ucsd.edu

References <KENJI.93Nov21192404@reseau.k2r.or.jp>, <2cp3dk$lls@unicorn.ccc.nottingham.ac.uk>, <2ctp3q$h25@wvhpadm1.mentorg.com> 
Subject : Re: wb7tpy gateway


In article <2ctp3q$h25@wvhpadm1.mentorg.com>, hanko@wv.mentorg.com (Hank Oredson) writes:
> [...]
> And that Namibia is in Africa and not in North America.
> And is never addressed with one of those really stupid internet
> TWO letter designations.  At least we got one thing right in
> the bbs network: we used the THREE letter country codes ...

Err, the site that ended up with a pile of xxx.usa.na messages
was in Namibia, and it's official domain name *did* end in .na
Actually, since the guy had to pay for all those messages to
get delivered over a long distance UUCP connection, and then
pay again while they bounced (until he at least stopped that),
I thought he was more than reasonable about the whole affair..

> And any reasonable router should be able to tell the difference
> between USA.NA and something in Namibia - or does Namibia have
> a USA sub-domain ?

And here we have it, the "left to right" parsing thinking that
brought you the # fields in PBBS addresses. If someone wants
to call a domain in Namibia "usa" then they are entitled to.

Sigh..
-- 
andyw N0REN/G1XRL

andyw@aspen.cray.com Andy Warner, Cray Research, Inc. (612) 683-5835

------------------------------

Date: Sat, 27 Nov 1993 21:25:15 GMT
From: swrinde!gatech!europa.eng.gtefsd.com!paladin.american.edu!darwin.sura.net!ra!atkinson@network.ucsd.edu
To: ham-digital@ucsd.edu

References <CGrL57.6Iq@usenet.ucs.indiana.edu>, <1993Nov22.191806.11611@hplabsz.hpl.hp.com>, <2ctnrt$ocf@newsserv.cs.sunysb.edu>
Subject : Re: ATM on Amateur Radio?

In article <2ctnrt$ocf@newsserv.cs.sunysb.edu> rick@cs.sunysb.edu (Rick Spanbauer) writes:

> You're confining yourself with how ATM might apply to 
> existing amateur packet.  Bandwidth allocation similar
> to ATM might make sense in a full duplex system where a
> hub would have to decide how to split up its forward
> channel bandwidth among the client nodes.  
>
>    Rick Spanbauer, WB2CFV

ATM/RF doesn't make much sense.  We've been looking into it for
hypothetical use with Navy radios and very rapidly concluded that
ATM/RF lost big.  If even one ATM cell has a bit error at the
receiver, the entire AAL frame has to be retransmitted.  Consider that
IP/AAL5 uses 9180 as the MTU size, that there are 48 octets of user
data per 53 octet ATM cell, that the typical bit error rate of an RF
channel is high, and the bandwidth costs of solid ECC.  By contrast,
IP/RF works reasonably well and is currently used by a large number of
non-commercial, commercial and government users.

A lower overhead and technically superior solution for bandwidth
reservation would be to use a resource reservation protocol
(e.g. RSVP, which is being proposed for use with IP).  ATM doesn't
handle bandwidth reservation very effectively -- though the marketing
droids tout bandwidth reservation as an advantage.

ATM also has potentially severe problems with switch congestion and
cell loss.  The main way that real ATM users are coping with this
switch problem is the traditional telco solution (over-engineer the
network big-time) and this is expensive to do.

In short, wise folks will soon understand that ATM is mostly hype at
this point, that it is NOT a panacea, and that it probably can't be
usefully extended very far outside its design objective (connecting
fiber optic circuits together for telephone companies and for high-
bandwidth fiber-optic computer communications circuits).

Ran
atkinson@itd.nrl.navy.mil
(who until very recently was working on ATM full-time)
employed by, but not speaking officially for the
 Information Technology Division, Naval Research Laboratory...

------------------------------

Date: 25 Nov 1993 11:28:14 -0000
From: pipex!uknet!warwick!unicorn.nott.ac.uk!unicorn.nott.ac.uk!not-for-mail@uunet.uu.net
To: ham-digital@ucsd.edu

References <2ctp3q$h25@wvhpadm1.mentorg.com>, <1993Nov23.163518.13551@hemlock.cray.com>, <2d08eo$mi4@wvhpadm1.mentorg.com>k
Subject : Re: wb7tpy gateway

In article <2d08eo$mi4@wvhpadm1.mentorg.com> Hank_Oredson@mentorg.com writes:
>In even simpler terms: once the application has parsed off the
>very last field (NA) and then looks at the next field (USA), it
>can certainly notice that there ARE no sub-domains USA.NA in
>Namibia ... or is the Internet addressing scheme to stupid to
>allow for things like this?
A quick DNS trawl courtesy of nslookup reveals:

 na.                            SOA   rain.psg.com hostmaster.ns.psg.com. (9307100 345600 7200 2592000 691200)
(snip)
 na.                            MX    10   kudu.ru.ac.za
 na.                            MX    20   hippo.ru.ac.za
 na.                            MX    100  rip.psg.com
 na.                            MX    150  m2xenix.psg.com
 *                              MX    10   kudu.ru.ac.za
 *                              MX    20   hippo.ru.ac.za
 *                              MX    100  rip.psg.com
 *                              MX    150  m2xenix.psg.com

So, all mail to Namibia should go through South Africa anyway. What happens
then depends on what ru.ac.za does with it.. hopefully, it'd be sensible enough
to bounce anything @n9zzz.#zz.usa.na. If it doesn't, something's broke
somewhere..

Mike

-- 
+- Mike Knell, University of Nottingham, UK -=- M.Knell@unicorn.nott.ac.uk --+
|  --THIS SPACE TEMPORARILY BLANK--   | AMPR: g7gpa@hobbes.g7gpa.ampr.org    |
| (until I can think of a decent joke)| AX25: g7gpa@g7gpa.gb7bad.#23.gbr.eu  |
|UNDER the overpass! OVER the underpass! Around the future and BEYOND REPAIR!|

------------------------------

End of Ham-Digital Digest V93 #126
******************************
******************************
